1. Technical Field
The present invention relates generally to an improved data processing system. In particular, the present invention provides a method, system, and computer program instructions for allowing a user to transparently navigate through multiple Network File System version 4 exported file system boundaries using a single client side network mount.
2. Description of Related Art
A network file system (NFS) is a client-server application that allows network users to manage files on several computers inside a network as if they were on the local hard disk. Some computer systems, especially those running a Microsoft operating system such as Windows, generally attach all branches (file systems or directories) of a directory tree upon startup. However, UNIX-based computer systems typically do not do so. UNIX-based systems usually only attach certain branches to the directory tree on startup. These attached branches contain files that are critical for the operating system to function properly. The other file systems are mounted only when needed. Thus in the current UNIX world, when a user on one machine attempts to access information within a file system on a different machine, the user must perform some kind of network mount to establish a connection between the two machines. Many networked installations currently perform mounts by using a network file system (NFS) protocol, such as Network File System version 4 (NFSv4). NFS is a distributed file system protocol that provides remote access to shared files systems across networks. With NFS, computer systems connected to a network operate as clients when accessing remote files and as servers when providing remote users access to local shared files.
When a user on machine A wants access to files on machine B, the user mounts the file system from a server machine, and thus integrates the file system into the machine A's directory tree. The user also specifies where in the directory tree the files should appear. The directory given is called the mount point. A mount point is an empty directory or subdirectory that is created as a place to attach a remote file system. If the user on machine A wants to access information in another file system on machine B, the user must perform another network mount to establish another connection between the two machines in order to do so.
For example, a user on client machine A wants to gain access to three different file systems on server machine B. These file systems may be named “/usr”, “/usr/local”, and “/usr/local/bin”. In response to the request from the user on machine A, the system administrator on server machine B exports those three file systems, “/usr”, “/usr/local”, and “/usr/local/bin”, allowing access for client machine A. By exporting the file systems, the file systems become available for the system administrator to mount on machine A. In response, system administrator on machine A establishes a connection using an NFS mount for exported file system “/usr”. Once the exported file system “/usr” is mounted, data within the “/usr” file system is now available to the user on machine A. However, in order for the user to also have access to the “/usr/local” and “/usr/local/bin” file systems, the system administrator must also perform two additional mounts to establish a connection via NFS for exported file system “/usr/local”, and to establish a connection via NFS for exported file system “/usr/local/bin”.
For security purposes, in some implementations of UNIX, such as Advanced Interactive executive (AIX), only users who belong to an administration group on the system can perform mounts and establish the connection between machines. Consequently, it is problematic for other users who do not belong to that special group because they do not have the sufficient rights to perform the mounts.
Current server side mechanisms exist that allow for traversing exported file systems without performing network mounts for each file system. For example, in NFS version 4, a pseudo file system is introduced which provides a link between all of the exported file systems on the server. A pseudo file system is used to connect exported file systems. With a pseudo file system, the server must fill in gaps for directory components between different exported file systems, and allow client requests to cross exported file system boundaries. Additionally, the server must return pseudo (fake) directory information to clients that have not been given export access to involved data. The pseudo file system model results in the server exporting a single file namespace that is in reality a collection of connected individual file systems. Each of the file systems is represented as a unique fsid attribute value in the NFSv4 protocol.
An fsid is an NFSv4 protocol concept that describes a collection of filesystem objects (files, directories, etc.), which have a common set of properties about them. Properties such as the maximum supported filename length and the ability to support setting access control lists (ACLs) are examples of fsid wide properties. In most UNIX NFS server implementations, it is common that the assigned fsid value will equate to an instance of a filesystem that is exported by the NFS server to NFS clients. However, this does not have to be the case. The server may have other methods to group together collections of data that it represents as an fsid.
Thus, from the client, there is a single exported file system space presented by the NFSv4 server. For example, the server exports two directories—“/usr” and “/usr/local/bin”. In NFSv4, if “/usr/local” is not exported, the server must provide “/usr/local” as a pseudo file system node to allow clients to traverse from “/usr” to “/usr/local/bin” without receiving a “no such file” error for “/usr/local”. With this server model, clients may exploit the above capability provided by the protocol to create an NFS mounted file system that allows a user to traverse between exported file systems (fsids) with only a single mount at the root of the server's exported file space.
Historically, NFS client platform developers have implemented client side auto file system (autofs) mount solutions that allow users to access different exported file systems on the server without the requirement to manually perform the actual network mounts. However, none of these existing implementations provide transparent mounts to the user and they require additional administration independent of the actual NFS file servers to define the mounting rules. Administrators must ensure the consistency of the rules and the actual exported data that resides on server systems. These peripheral solutions have been problematic to deploy due to lack of standardization, availability on the different client platforms, and inconsistent quality. Ultimately, the administrative overhead of autofs is high. Thus, existing solutions are not highly transparent to client users, they require greater administrative overhead, and they have proved difficult to deploy and manage.
The NFSv4 protocol and its server pseudo file system export model create an opportunity for new methods at the client to achieve a single unified namespace view across a collection of exported file systems (fsids) at a server. New methods would increase the transparency of the namespace by eliminating client side artifacts such as UNIX mounts for each fsid. Clients utilizing these techniques can operate without the need for peripheral technologies such as autofs, they can lower overall administration costs, and they can be more adaptable to changes in the data environment such as new data creation or movement of data from one server to another.
Therefore, it would advantageous to have a mechanism that allows a user to transparently navigate through multiple exported file system boundaries using a single client side network mount.